In article <3f21a958$1@news.povray.org>, tho### [at] trfde says...
> I am still undecided whether I should recommend some sleep or you are on
> drugs.  There is neither head nor tail to what you are writing.  I don't
> even know how to respond to this in a meaningful way!?! :-(
> 

Ok.. Then let me try again...

I could make a file with the same name as flyer_2000 is talking about on 
my windows machine. It would look different in a DOS window, since 
Windows doesn't use the OEM terminal font in most programs, even for 
dealing with filenames. However, the file system would have absolutely no 
problem with it and 'in windows' it would have the proper accented 
character. This does not make it a unicode name. I am not sure what the 
technical name for a character set that has exactly 255 characters is, 
but it isn't exactly ASCII and it also isn't Unicode.

So I am unclear about exactly 'which' OS you seem to think would have a 
problem here? Windows will accept the name, I am fairly sure Unix based 
systems would, maybe Mac 'might' have a problem, but the only 'real' 
issue is the font used to display the names, which differs between a DOS 
window and Windows, but 'should' be the same under most GUI environments.

If you still don't believe me, then consider that these sorts of 
characters have also been used in text documents since before Windows 3.1 
and on 9x systems you have to install Unicode support separately, because 
it is not a native part of the OS. If such file names and characters can 
only happen with Unicode, then how they heck do you explain them existing 
before Unicode was available?

So again. Exactly 'which' OS are you saying is not capable of using this 
particular set of files? You are the one that assumed he was talking 
about unicode and brought that into the discussion, but such a name is 
not unicode.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message